1. Field of the Invention
The present invention relates to a push-to-talk-over-cellular (PoC) system, and more particularly to a technique of resetting a floor (a right to speak) in an environment where a function of managing the floor is provided in a PoC system.
2. Description of the Related Art
Due the significant development of mobile communications technology and extension of mobile communications networks, various extra services and applications which make use of a cellular phone are being provided. At the same time, demand among cellular phone users for various extra services, such as a location service, a multimedia service, and a push-to-talk (PTT) service, is increasing. Among these extra services, the PTT service supports various supplementary functions such as an instant messenger function and a status display function, as well as a group call and a voice call, which may also be provided by an existing radio or a trunk radio system (TRS).
Currently, standardization of a push-to-talk-over-cellular (PoC) service which employs the PTT function in a mobile communication network is actively proceeding. One unique feature of the PoC service is that a user can participate in a plurality of PoC sessions, and can move among the PoC sessions to use a call service. Requirements enabling a user to move among the plurality of PoC sessions to use the call service are specified in the Open Mobile Alliance (OMA), which is a forum for specifying mobile communications services.
The structure of an ordinary PoC service system will be explained with reference to the.
schematic diagram of FIG. 1. Referring to FIG. 1, a PoC client 10, as a service requester installed in a mobile station, is mostly connected to a Session Initiation Protocol/Internet Protocol (SIP/IP) core network 30 which supports SIP and IP multimedia functions via an access network 20.
The PoC client 10 resides in a PoC user terminal to provide access to the PoC service. The PoC client 10 mainly serves to establish a PoC session, participate in a PoC session that is currently proceeding, and terminate a PoC session. In addition, the PoC client 10 acts to make and transfer a talk burst, support an instant personal alert, and perform authentication when accessing the PoC service. Hereinafter, unless otherwise stated, both the PoC user and the PoC client 10 are assumed to be the same as a PoC service subscriber.
The SIP/IP core network 30 is connected to a PoC server 60, a GLMS (Group List and Management System) 50, and a presence server 70 in order to support the PoC service.
At this time, the PoC server 60 serves as a Controlling PoC Function (CF) for maintaining and managing a PoC session, or a Participating PoC Function (PF) for participating in a PoC session for a one-to-one PoC call or a one-to-many PoC call (or group PoC call).
Functional blocks of the PoC server will be explained below with reference to to schematic diagram of FIG. 2.
The PoC server is classified into a Controlling PoC Function of taking charge of overall maintenance and management of a PoC session and a Participating PoC Function (PF) of taking charge of maintenance and management between each PoC session, which will be explained with reference to the tables below.
TABLE 1Controlling PoC Function (CF)Provides centralized PoC session handlingProvides centralized Media distributionProvides centralized Talk Burst Arbitration functionality includingtalker identificationProvides SIP session handling, such as SIP session origination,termination, etc.Provides policy enforcement for participation in group sessionsProvides participant informationCollects and provides centralized media quality informationProvides centralized charging reportsMay provide transcoding between different codecsSupports Talk Burst Control Protocol Negotiation
As shown in Table 1, the CF serves to maintain and manage a PoC session on the whole. The PoC server receives requests for a floor from PoC clients, arranges an order in which to give the clients the floor, and gives the clients the floor in that order. The PoC server also distributes a talk burst, for which an arbitrary PoC client makes a request, to all other PoC clients participating in a group PoC call, and provides information of the PoC clients participating in the group PoC call.
As shown in Table 2 below, the PF manages a PoC session between the CF and each PoC client. In particular, the PF acts to relay the floor between the PoC client and the CF when the PoC client makes a request for the floor or when the CF gives the floor to the PoC client. In addition, the PF serves to relay media between the CF and the PoC client, perform transcoding between different codecs, and filter one of two concurrent PoC sessions according to the choice of a PoC user when there is simultaneous talking in the two concurrent PoC sessions.
TABLE 2Participating PoC Function (PF)Provides PoC session handlingMay provide the Media relay function between PoC client and ControllingPoC serverMay provide user media adaptation proceduresMay provide the Talk Burst control message relay function between PoCclient and Controlling PoC serverProvides SIP session handling, such as SIP session origination,termination, etc, on behalf of the represented PoC client.Provides policy enforcement for incoming PoC session (e.g.access control, incoming PoCsession barring, availability status, etc.)May collect and provide media quality informationProvides the participant charging reportsMay provide filtering of the media streams in the case of simultaneoussessionsMay provide transcoding between different codecsMay support Talk Burst Control Protocol NegotiationStores the current Answer Mode and Incoming PoC Session Barringpreferences of the PoC client
In the PoC service system as described above, the PoC user can input information on a group and its members to the GLMS 50 through his/her PoC terminal, and can be aware of information about PoC users who he or she can call through individual or group list transmitted from the GLMS 50. Alternatively, the information on the group and its members may be input, corrected and managed in the GLMS 50 via a reliable communication network such as the Internet or Intranet which a PoC service provider can trust.
In order to make use of the PoC service, the PoC user registers his/her PoC address with the SIP/IP core network 30. The SIP/IP core network 30 stores PoC user information at the request of the PoC user. Thus, when another PoC user tries to request a group PoC call, the PoC user registers his/her information in the SIP/IP core network 30 in advance as described above, and requests the group PoC call to his/her SIP/IP core network 30 by using group identification information transmitted from the GLMS 50. At this time, the SIP/IP core network 30 performs address determination and domain location determination by using information of the call requesting PoC user and then transfers a PoC call request to a home PoC server with which the call requesting PoC user is registered. In regard to the PoC call request, the PoC server prepares for establishment of a PoC session, obtains each user's information from the GLMS 50, and then transfers a PoC call request signal to a corresponding SIP/IP core network 30. Here, in the case of a PoC call request to users within an Intradomain, the PoC server performs both the CF and PF. The PoC server, which manages a call-requested PoC user, requests a PoC call to the PoC user after the SIP/IP core network 30 performs the location determination procedure, by using information of the PoC user that is transmitted to the PoC server.
FIG. 3 is a schematic of explaining CF and PF blocks of a PoC server.
Referring to FIG. 3, PoC clients 111, 121, 131 and 141 provide access to a CF 100 through PFs 110, 120, 130 and 140 respectively, thereby establishing a PoC session. Here, when a floor is granted to a requester qualified as a talker from the CF 100, media based on speaking of the corresponding PoC client is transmitted to each PoC client.
FIG. 4 is a flow diagram illustrating a general procedure where a PoC user obtains a floor.
Referring to FIG. 4, in order to obtain a floor, a PoC client A 111 presses a PoC talk button installed in his/her own PoC terminal when no PoC client is talking within a PoC session where the PoC client A 111 is connected to a PoC client B 121.
Therefore, the PoC client A 111 transmits a message making a request for the floor, a Talk Burst Request message, to a PF A 110 acting as Participating PoC Function (S101). Thus, the PF A 110, that receives the Talk Burst Request message, transmits the Talk Burst Request message to a CF 100, a PoC server, acting as Controlling PoC Function of this PoC session (S101).
After receiving the Talk Burst Request message, the CF 100 transmits a message notifying that the floor is granted, a Talk Burst Confirm Response message, to the PoC client A 111 (S102) as well as a message notifying that the floor has been granted to the PoC client A 111, a message of Receiving Talk Burst from User A, to the PoC client B 121 (S103). Since the latter message includes an identifier (ID) of the PoC client A 111 who is qualified as the talker, the PoC client B 121 knows who the talker is.
Thereafter, a media session is opened, and a talk burst, a Media, is transmitted from the PoC client A 111 to the PoC client B 121 (S104).
The foregoing description is directed to the procedure of making a request for the floor when the PoC session is connected. When the PoC session is not connected, the PoC client A 111 makes a request to the PoC client B 121 to set up the PoC session, and then the PoC server, that acts as the Controlling PoC Function between the two clients, transmits a message relating to establishment of the PoC session to the PoC client B 121. Then, the PoC client B 121 transmits a compliance response to the request to the CF 100 of the PoC server which acts as the Controlling PoC Function, and thus the CF 100 transmits the Talk Burst Confirm Response message to the PoC client A 111. In this manner, the PoC client A 111, that is granted the floor, transmits speaking (a data file converted into a voice signal) through the opened media session when beginning to talk with his/her PoC talk button pressed.
FIG. 5A is a flowchart showing a general procedure of reserving a floor at a terminal.
Referring to FIG. 5A, a PoC user participates in a PoC session, and receives a talk burst from at least one of the other participants who participate in the PoC session (S201). When wishing to talk, the PoC user presses a talk button equipped with his/her PoC terminal. It is determined whether the PoC user has pressed the talk button (S202). In step S202, if it is determined that the PoC user has pressed the talk button, it is determined whether the other participant is transmitting a talk burst (S203).
In step S203, if it is determined that the other participant is not transmitting the talk burst, the PoC user makes a request for a floor, receives a Talk Burst Granted message, and transmits the talk burst (S210).
In step S203, if the other participant is transmitting the talk burst, it is then determined whether a floor management function (e.g. a “queue” function) is supported (S220). If the other participant is transmitting the talk burst and when the floor management function is supported, the floor is reserved at a floor manager when the floor is requested (S230). This floor is reserved in a queue of a PoC server acting as the Controlling PoC Function.
In step S220, if it is determined that the queue function is not supported, the terminal may not request the floor. And, even if the terminal requests the floor, the reservation of the floor is denied at the PoC server acting as the CF (S240).
FIG. 5B is a flowchart showing a general procedure of managing a floor at a PoC server.
Referring to FIG. 5B, the state of a PoC server may be divided into two in a PoC session: an idle state and a state of transmitting of the talk burst of a PoC user (S301). When a floor is requested (S302), when a floor management function (e.g. a “queue” function) is supported (S303), and when any other participant is transmitting a talk burst (S310), the PoC server acting as the CF reserves the requested floor in a floor management list (S311). In step S310, if it is determined that the other participant is not transmitting the talk burst, the PoC server transmits a Talk Burst Granted message to the terminal of a PoC client requesting the floor, and transmits (relays) the talk burst received from the PoC user to the other listeners who participate in the PoC session (S312).
When the floor is requested, and the floor management function is not supported, and when the other participant is transmitting the talk burst (S320), the PoC server acting as the CF denies the requested floor (S321). When the floor management function is not supported and when the other participant is not transmitting the talk burst, the PoC server transmits a Talk Burst Granted message to the terminal of the PoC client requesting the floor, and transmits (relays) the talk burst received from the PoC user to the other listeners who participate in the PoC session (S322).
FIG. 5C is a flow diagram showing a process of reserving a floor in a general PoC system.
Referring to FIG. 5C, while a PoC client B 121 transmits the talk burst (S401), a PoC client A 111 makes a request for a floor, i.e. transmits a Talk Burst Request message (S402). In this case, a PoC server X 100 acting as the CF reserves the floor in a floor management list (e.g. a “queue”) (S403), and transmits position information on the reserved floor (i.e. a speaking order) to the PoC client A 111 (S404).
At this time, the reserved floor position information may be notified through the Talk Burst Queue Position Status message of an RTCP APP (Real-time Transport Control Protocol Application) packet. In the foregoing manner, the PoC user can know whether the floor requested by the PoC user is reserved in the floor management list
FIG. 6 is a flow diagram showing a process where, when there is a floor reserved in a floor management list in a general PoC system, and when one of the other participants terminates speaking, another participant having the next floor transmits a talk burst.
Referring to FIG. 6, a PoC client A 111 transmits a talk burst (S501), and a PoC user releases a talk button equipped with his/her PoC terminal as speaking comes to end. Then, the PoC client A 111 transmits a final packet to be transmitted to a PoC server X 100 performing the CF (S502), and transmits a message notifying that transmission of the talk burst is completed, namely a Talk Burst Completed message (S503). At this time, the PoC server X 100 transmits the finally received packet to a PoC client B 121 (S502), recognizes that the transmission is completed through the Talk Burst Completed message received from the PoC client A 111, and transmits a Talk Burst Confirm message implying that the PoC client A 111 may speak to the PoC client B 121 having the next floor (S504). The PoC client B 121 receiving the Talk Burst Confirm message displays a content that the PoC client A 111 may speak on a display unit of the terminal of a PoC user B. From this point, the PoC user B speaks with a talk button pressed (S505).
The prior art of reserving the floor in the floor management list (e.g. the queue) as mentioned above has an advantage that it is possible to effectively operate the PoC system as compared with the function capable of requesting the talk burst only whenever the PoC session is in the idle state.
However, in the prior art the following problem may occur in the case of making a conference call in the PoC system environment. In the case of the conference call, a plurality of PoC users make a request for the talk burst in order to speak about one subject. For example, in a state where about 20 floors are reserved, when there occurs a situation of easily drawing a conclusion or requiring urgent discussion on another matter when about three PoC users speak, it is not until all the remaining 17 PoC users gain the floor to complete speaking that they can proceed to a new matter. This causes a waste of wired/wireless resources as well as wasting time in the PoC system.